На встречи нашего Сообщества регулярно приходят аналитики, тестировщики, технические писатели, которые недовольны непредсказуемостью работы в проекте и спрашивают: "Как продать бизнес-анализ своему текущему руководителю".

Признаюсь, что сама неоднократно занималась этим неблагодарным делом. И ни разу мои усилия не увенчались успехом, т.е. ни результаты бизнес-анализа не были в сколько-нибудь серьезном объеме взяты в работу, и процессы работы в команде не перестраивались в обозримом будущем.

Почему же это не получилось не смотря на то, что я была уверена в целесообразности и качестве моей работы? На мой взгляд, по причине того, что я "продавала" бизнес-анализ не тем людям, не понимала интересов руководителей.

Расскажу, что говорят про это сами руководители, критерии выбора "продавать/не продавать", которые я выбрала для себя.
 

Для большинства сервисов, как правило, существует ограниченный набор вариантов пользовательского взаимодействия. Главенствующую роль здесь играют нефункциональные требования. Именно от их соблюдения и зависит качество работы сервиса. А можете ли вы с уверенностью сказать, что, например, производительность вашей системы, соответствует требуемой? На чем основана ваша уверенность? Когда у вас нет средств контроля, эксплуатация такой системы подобна езде по скоростной автостраде с закрытыми гразами. В своем докладе, я хочу рассказать о том, как мы "открывали глаза" создавая систему контроля нефункциональных требований, с какими проблемами нам пришлось столкнуться и какие мы из всего этого сделали выводы.

Представьте себе, что вы как аналитик попали в проект со сложившейся историей разработки и взаимоотношений с Заказчиком. Какие сюрпризы поджидают аналитика на таких проектах,  чего ждать и к чему готовиться? Что нужно будет делать и с чем смириться, а что лучше не делать? Об этом я расскажу в своем докладе.

Доклад ориентирован на начинающих аналитиков.

Цель доклада - сформировать представление об основных ситуациях, с которыми аналитик может столкнуться на проектах с историей,  а также вариантах решений для выхода из них.

Разрабатывая новую информационную систему или внедряя уже существующую, вы неизбежно сталкиваетесь с необходимостью определить нефункциональные требования к вашей системе. 

Выступление о том, какими бывают нефункциональные требования, как их определять и как с ними работать.

Многие годы практически применимые описания решений (англ. decision) и бизнес-правил (англ. business rule, BR) строились на основе математических формул, естественных языков и имели вид слабо формализованных матриц и каталогов. Ситуация решительным образом изменилась в сентябре прошлого года, с выходом в свет спецификации Object Management Group, представившей принципиально новую нотацию и подход к моделированию Decision Model and Notation (DMN™).

Отличительными чертами DMN являются компактность и простота, а также возможность эффективно использовать DMN совместно с нотацией и подходом к моделированию бизнес-процессов BPMN. Кроме того, владение DMN как передовым стандартом бизнес-моделирования постепенно и неуклонно становится одной из базовых компетенций современного аналитика.

В рамках предстоящего мероприятия, — которое скорее будет похоже на мастер-класс, а не классический «круглый стол», — мы не только познакомимся с нотацией DMN 1.0, но и решим несколько практических задач по моделированию решений и бизнес-правил, в том числе в контексте совместного применения DMN и BPMN 2.0.

Докладчик Рахимова Гузель, компания “Центр Высоких Технологий”

Вопросы:

• Пользовательские аспекты

• Технологические и технические аспекты

Тезисы:

В своем докладе я хочу раскрыть вопросы, связанные с анализом требований для мобильных приложений. На что следует обратить внимание в первую очередь при проектировании пользовательского поведения, какие бывают технологические ограничения и каким образом лучше проводить согласование работ.

Кратко о себе:

Рахимова Гузель, https://www.facebook.com/r.guzelle

Руководитель проектов, ведущий аналитик

1. Какие методики проектирования приняты на веб-разработке - и почему они работают через пень-колоду;

2. Что такое продукт - и почему понимать проектирование продукта в 100 раз важнее, чем проектирование интерфейсов;

3. Проектирование продукта по методу "тупо в лоб": плюсы, минусы, адские моменты;

4. Проектирование продукта по гибкой методологии: противостояние хаосу методом хаоса;

5. Почему вам нужно забыть про ТЗ, прототипы и прочие артефакты - и что нужно помнить взамен.